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MEDICAL PERFUSION SYSTEM 



Background of the Invention 
5 The present invention is directed to a medical perfusion 

system adapted to handle the selective oxygenation, filtering 
and recirculation of blood in connection with various medical 
procedures . 

A conventional perfusion system may be used to oxygenate, 

10 filter, and/or recirculate the blood of a patient during a 
medical procedure. Such a perfusion system may have a fluid 
conduit that removes blood from the patient during the medical 
procedure, a separate fluid conduit that returns blood to the 
patient, one or more blood pumps that pump blood through the 

15 conduits, and a plurality of sensing devices, such as flow 
sensors and/or level sensors associated with blood pumps. The 
perfusion system may also include air embolus sensors, 
temperature sensors, flow occluders, etc. 

Typically, a perfusion system is provided with a 

20 configuration specifically designed to be used for a particular 
purpose. For example, one perfusion system may be specifically 
designed as a full- function heart /lung machine, while another 
perfusion system may be specifically designed as a ventricular- 
assist system. Although it may be possible to convert a 

25 perfusion system designed for one purpose to a perfusion system 
usable for a different purpose, such reconfiguration is 
generally difficult and/or time-consuming. 

Summary of the Invention 

30 The invention is directed to a medical perfusion system 

for use in connection with the medical treatment of a patient. 
The perfusion system includes a first type of perfusion device 
in the form of a blood pump adapted to pump blood through a 
fluid conduit connected to the patient, a second type of 

35 perfusion device in the form of a sensor adapted to sense a 
condition relating co the pumping of blood through the fluid 
conduit and to generate a sensing signal relating to the 
condition, and a data communications network for operatively 
interconnecting the perfusion devices. The perfusion system 
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also includes means for transmitting messages in the form of 
digital data packets among the perfusion devices over the data 
communications network and a controller operatively coupled to 
the perfusion devices via the data communications network, the 
5 controller having an input device for accepting pump control 
commands from an operator. 

The data communications network may be provided with a 
plurality of network connectors, each of which has an identical 
connector configuration, and the perfusion system may include 

10 at least two adapter pods, each of which has a common connector 
adapted to be coupled to one of the network connectors and a 
device connector adapted to be coupled to one of the perfusion 
devices. The message transmitting means may include means for 
generating a message containing a control command for the pump 

15 and means for generating a message containing data relating to 
the sensed condition. 

The controller may include a plurality of network 
connectors, and the data communications network may include a 
network extender having a network connector adapted to be 

2 0 coupled to one of the network connectors of the controller, a 

plurality of extender connectors adapted to be connected to the 
common connectors of the adapter pods, and a data bus 
electrically interconnecting the network connector of the 
network extender with each of the extender connectors. 
25 In another aspect, the invention is directed to an adapter 

pod for use in a medical perfusion system having a data 
communications network with a plurality of connection points 
each having a substantially identical network connector. The 
adapter pod includes a common connector adapted to be connected 

3 0 to one of the network connectors, a device connector adapted 

to be connected to a perfusion device, and means for generating 
a message in the form of a digital data packet. 

These and other features of the invention will be apparent 
to those of ordinary skill in the art in view of the detailed 
35 description of the preferred embodiments, which is made with 
reference to the drawings, a brief description of which is 
provided below. 
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Brief Description of the Drawings 
Fig. 1 is a block diagram of a preferred embodiment of a 
perfusion system in accordance with the invention; 

Fig. 2 is a perspective view of the main controller shown 
5 schematically in Fig. 1; 

Fig. 3 is a perspective view of one of the network 
extenders shown schematically in Fig. 1; 

Fig. 4 is a perspective view of one of the adapter pods 
shown schematically in Fig. 1; 
10 Figs. 5-7 illustrate a number of connector configurations; 

Fig, 8 is a perspective view of the main controller shown 
schematically in Fig. 1 with two network extenders and eight 
adapter pods plugged therein; 

Fig. 9 is a block diagram of the main controller shown 
15 schematically in Fig. 1; 

Fig. 10 is a block diagram of one of the extender 
controllers shown schematically in Fig. 1; 

Fig. 11 is a block diagram of one of the node controllers 
shown schematically in Fig. 1; 
20 Fig. 12 is a block diagram of one of the adapter pods 

shown schematically in Fig. 1; 

Figs. 13A-13H are flowcharts illustrating the operation 
of the main controller shown in Fig. 1; 

Figs, 14A-14B are exemplary illustrations of a pair of 
25 perfusion circuit images generated on the display device of 
Fig. 9 during operation of the perfusion system; 

Figs. 15A-15C are flowcharts illustrating the operation 
of the extender controllers shown in Fig. 1; 

Figs. 16A-16B are flowcharts illustrating the operation 
3 0 of the node controllers shown in Fig. 1; and 

Figs, 17A-17D are flowcharts illustrating the operation 
of the adapter pods shown in Fig. 1. 

Detailed Description of the Preferred Embodiments 
35 Fig. 1 illustrates a preferred embodiment of a medical 

perfusion system 10 in accordance with the invention. The 
perfusion system 10 is adapted to handle the selective 



oxygenation, filtering and recirculation of blood in connection 
with a number of different medical procedures. The perfusion 
system 10 may be placed in a number of different 
configurations, each of which corresponds to a different 
5 medical procedure. For example, the perfusion system 10 may 
be configured as a full -function heart/lung machine, a 
ventricular assist system, or a single-pump system that can be 
used for various purposes, such as to perform blood aspiration 
or myocardial protection during surgery. 

10 Referring to Fig. 1, the main controller 20 is connected 

to a network extender 22a via a data/power bus 3 0a and to a 
network extender 22b via a data/power bus 30b. The network 
extender 22a includes an extender controller 32a connected to 
three node controllers 34a, 34b, 34c via a data/power bus 30c. 

15 The node controller 34a is connected via a data/power bus 3 0d 
to an adapter pod 4 0a, which is in turn connected to a 
perfusion device 50 in the form of a flow sensor 50a via a 
bidirectional data/power line 52a. The node controller 34b is 
connected via a data/power bus 30e to an adapter pod 40b, which 

20 is connected to an air embolus sensor 50b via a bidirectional 
line 52b. The node controller 34c is connected via a 
data/power bus 3 Of to an adapter pod 40c, which is connected 
to a blood pump 50c via a bidirectional line 52c. 

The network extender 22b includes an extender controller 

25 32b connected to three node controllers 34d, 34e, 34f via a 
data/power bus 3 0g. The node controller 34d is connected via 
a data/power bus 3 Oh to an adapter pod 4 0d, which is connected 
to a pressure sensor 50d via a bidirectional line 52d. The 
node controller 34e is connected via a data/power bus 30i to 

3 0 an adapter pod 40e, which is connected to a temperature sensor 
50e via a bidirectional line 52e. The node controller 34f is 
connected via a data/power bus 30 j to an adapter pod 40f , which 
is connected to a flow occluder 50f via a bidirectional line 
52f . 

35 The main controller 20 is operatively coupled to a blood 

pump 50g via a bidirectional line 52g connected to an adapter 
pod 4 0g. The pod 4 0g is connected to the main controller 20 
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via a data/power bus 3 0k. The main controller 20 is 
operatively coupled to a level sensor 50h via a bidirectional 
line 52h connected to an adapter pod 4 Oh, which is connected 
to the main controller 20 via a data/power bus 301. 
5 As used herein, the term "perfusion device" is a device 

designed to be used in a medical perfusion system, including 
but not limited to a blood pump such as a centrifugal or roller 
pump, a flow sensor, a pressure sensor, a temperature sensor, 
a level sensor, an air embolus sensor or an occluder. 

10 

Mechanical Structure of Network Components 
Fig. 2 is a perspective view of a portion of one 
mechanical embodiment of the main controller 20. Referring to 
Fig. 2, the main controller 20 has four network connectors 60, 

15 which are shown schematically. Each of the network connectors 
60 is identical and has the same connector configuration. Fig. 
5 illustrates the structure of the connectors 60. As shown in 
Fig. 5, each connector 6 0 may be, for example, a standard 
personal computer connector having nine conductive pins 62 

20 partially surrounded by an asymmetrical metal housing 64. 

Fig. 3 is a perspective view of one embodiment of the 
network extenders 22 shown schematically in Fig. 1. Each 
network extender 22 has a hexahedral housing 66 with one side 
68 on which three connectors 70 are disposed and an opposite 

25 side on which a connector 72 is disposed. Each connector 70 
is identical to the connectors 60 and has the structure shown 
in Fig. 5. The connector 72, which is shown in Fig. 6, has 
nine pin receptacles 74 formed in an asymmetrical housing 76 
composed of an insulating material such as plastic. The pin 

30 receptacles 74 are located to correspond to the positions of 
the nine pins 62 of the connector 60. Consequently, the 
connector 72 has the same connector configuration as the 
connector 6 0 and thus can be plugged into the connector 60. 

Fig. 4 is a perspective view of the adapter pods 40 shown 

3 5 schematically in Fig. 1. Referring to Fig. 4, each adapter pod 
4 0 has a hexahedral housing with one side 82 on which a 
connector 84 is disposed and an opposite side on which a 



connector 86 is disposed. The connector 86 is identical to the 
connectors 72 described above (and shown in Fig. 6) . 

The connector 84 is adapted to be connected to a device 
connector (not shovm) that is associated with one of the 
perfusion devices 50 described above. The connector 84 has a 
different connector configuration than the connectors 60, 70, 
72, 86. One example of the structure of the connector 84 is 
shown in Fig. 7 to include six conductive pins 88. Since each 
of the adapter pods 4 0 is adapted to be connected to a 
different type of perfusion device 50 (the pumps 50c, 50g may 
be different types of pumps, such as a roller pump or a 
centrifugal pump) , the connector 84 disposed on each of the 
adapter pods 40 may have a different connector configuration. 

Since the connectors 60 of the main controller 20 and the 
connectors 70 of the network extenders 22 have the same 
connector configuration as the connector 86 of the adapter pods 
40, it should be noted that any of the adapter pods 4 0 may be 
plugged into any of the connectors 60, 70. As a result, any 
combination of perfusion devices 50 may be connected to the 
main controller 20. 

Fig. 8 illustrates the main controller 20 having the 
network extenders 22 and the adapter pods 40 connected to it. 
Each of the adapter pods 4 0 of Fig. 8 would be connected to a 
respective one of the perfusion devices 50 shown in Fig. 1 via 
a respective connector (not shown) attached to the perfusion 
device 50 by a cable. 

Although the form of the network extenders 22 shown in 
Figs. 3 and 8 makes the resulting control unit compact, network 
extenders having different structures could be used. For 
example, instead of having the connector 72 fixed on the 
housing 66, the connector 72 could be connected to the housing 
66 via a cable. Alternatively, the housing 66 could be 
eliminated, and the connectors 70, 72 could be interconnected 
via cables. 



Electronics 

Fig. 9 is a block diagram of the main controller 2 0 shown 
schematically in Fig. 1. Referring to Fig. 9, the main 
controller 20 has a microprocessor (MP) 100, a random-access 
memory (RAM) 102, a nonvolatile memory 104 such as a hard disk 
or a flash RAM, a network controller 106, a drawing controller 
108, and an input/output (I/O) circuit 110, all of which are 
interconnected by an address/data bus 112. The I/O circuit 110 
is connected to a display device 114, such as a CRT or a flat- 
panel display, and an input device 116, such as a keyboard or 
electronic mouse or a touch screen on the display device 114, 
The main controller 20 also includes a power supply 
circuit 118 that is connected to an outside source of AC power 
and which includes an internal transformer (not shown) that 
generates +5 volt and +24 volt DC power on a pair of electrical 
power lines relative to a ground line, which lines are 
schematically designated 120 in Fig. 9. The electrical power 
and ground lines 120 are provided to each of four node 
controllers 34g-34j via a data/power bus 30m and to the other 
node controllers 34 via the other portions of the network bus 
30. The data/power bus 30m includes a number of data 
communication lines which are connected to the network 
controller 106 . 

Fig. 10 is a block diagram of the extender controller 32a 
shown schematically in Fig. 1 (the design of the extender 
controllers 32a, 32b is the same) . Referring to Fig. 10, the 
extender controller 32a has a controller 130 and a switch 132, 
both of which are connected to the data/power bus 3 0a. The 
extender controller 32a is connected to its parent node 
controller 34g via a bidirectional signal line 133. As used 
herein, a "parent" device is a connected device that is closer 
to the network controller 106 (Fig. 9) of the main controller 
20. The node controller 34g transmits a unique physical 
address to the extender controller 32a via the line 133, and 
the extender controller 32a includes a driver circuit 135 which 
is used to periodically transmit a check-in code to the node 
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controller 34g via the line 133. The check-in code and the 
physical address may be the same binary code. 

Fig. 11 illustrates a block diagram of the node controller 
34a shown schematically in Fig. 1 (the design of all the node 
5 controllers 34 is the same) . Referring to Fig. 11, the node 
controller 34a has a controller 140 which receives an enable 
signal or a disable signal from the extender controller 32a via 
one of the lines 134 and a periodic check-in code from the 
adapter pod 40a via the line 133, The controller 140 is 

10 connected to a code generator 144 via a multi-signal line 146. 
The code generator 144 generates a predetermined mult i -bit 
binary code that uniquely specifies the physical address of the 
node controller 34a. The code generator 144 may be, for 
example, a number of printed metal circuit lines, one line for 

15 each bit of the code, each line being selectively connected 
either to +5 volts (logic "1") or to ground (logic "0"). 

The controller 140 selectively operates a switch 150 that 
either connects or disconnects a data bus 152, which may be 
composed of two individual data lines, that is part of the 

20 data/power buses 30c, 30d (and the other buses 30 that make up 
the network) . When the switch 150 is open, the data buses 3 0c, 
30d are disconnected, and when the switch 150 is closed, the 
buses 30c, 30d are connected to enable data communications 
between the adapter pod 4 0a and the other devices connected to 

25 the network 30. 

The controller 140 also operates a switch 154 that 
controls whether +24 volt DC power (relative to a ground line 
120c) on a electrical power line 120a is supplied to the 
adapter pod 40a and a switch 158 that controls whether +5 volt 

30 DC power on an electrical power line 120b is supplied to the 
adapter pod 40a. The electrical power lines 120a, 120b are 
part of the data/power buses 3 0c, 3 0d and the other buses 3 0 
that make up the network. A resistor 162 is connected in 
parallel with the switch 154, and a resistor 164 is connected 

35 in parallel with the switch 158. The resistors 162, 164 act 
as current -limiting resistors which prevent large amounts of 
current from being drawn from the power lines 12 0a, 120b when 
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the switches 154, 158 are open. The controller 140 is 
connected to a driver circuit 170 which is used to transmit the 
physical address generated by the code generator 144 to the 
adapter pod 40a via the line 133. 
5 Fig. 12 illustrates a block diagram of the adapter pod 4 0a 

shown schematically in Fig. 1. Referring to Fig. 12, the 
adapter pod 40a has a controller 180 which is powered by a 
power supply 182 connected to the electrical power lines 120a, 
120b. The controller 180 may transmit a check-in code on the 

10 line 133 via a driver 184. The controller 180 receives network 
messages from the data bus 152 and transmits messages onto the 
data bus 152 via a transceiver 186. 

The controller 180 is connected to a memory 188 and to a 
device interface circuit 190. The device interface circuit 190 

15 has a plurality of data lines 192 and a plurality of electrical 
power lines 194 which are connected to the perfusion device 50a 
via the connector 84 (Fig. 7) . The controller 180 causes 
various types of data signals to be transmitted to the 
perfusion device 50a via the data lines 192. 

2 0 Depending on the type of perfusion device 5 0 to which an 

adapter pod 40 is connected, the signals on the data lines 192 
might include, for example, digital or analog signals (e.g. 4- 
2 0 ma signals) relating to the control of the perfusion device 
50, such as a desired pump speed or mode of operation. The 
25 number of data lines 192 used depends on the particular 
perfusion device 50 to which the adapter pod 40 is connected. 

The controller 180 also causes various types of electrical 
power to be transmitted to the perfusion device 50 via the 
power lines 194. These types of power include, for example, 

3 0 +5 volt DC power or +24 volt DC power. If power of another 

voltage level is necessary, the power supply circuit 182 may 
comprise a DC/DC converter. 

Configuration and Display of Perfusion Circuit 
35 Prior to using the perfusion system 10 for a medical 

procedure, the operator connects the desired perfusion devices 
50 to the main controller 20 by physically connecting the 



desired adapter pods 4 0 and/or network extenders 22 to the main 
controller 20, as shown in Fig. 8. 

Prior to the commencement of a medical procedure, the 
perfusion system 10 is configured during a configuration 
process illustrated in Fig. 13A, which is a flowchart of a 
configuration computer program routine 200 executed by the main 
controller 20. Referring to Fig. 13A, at step 202 the program 
generates a visual prompt to the operator to request whether 
a previous configuration file should be loaded from the memory 
104 of the main controller 20. A configuration file generally 
includes image data corresponding to an image of a perfusion 
circuit, which may include an outline of the patient, images 
of a plurality of fluid conduits connected to the patient, and 
images of the various perfusion devices 50 used in the system 
10. Each perfusion device 50 may be represented by a different 
image, depending upon the type of perfusion device. For 
example, pumps may be represented by a pump image, whereas a 
flow sensor may have a different image. 

The configuration file may also include data relating to 
the perfusion devices 50, such as the manufacturer and model 
number of the device, the desired operational mode of the 
device, numeric limits at which an alarm should be triggered, 
and identification of any associated perfusion device. Two 
perfusion devices may be "associated" if one device that is 
used to control a physical process, referred to herein as a 
control device, is to receive feedback from another perfusion 
device, referred to herein as a sensing device. 

For example, referring to Fig. 1, the pump 5 0g could be 
controlled based on feedback generated by either the level 
sensor 50h (which would generate a signal indicative of fluid 
level within a fluid reservoir) or the flow sensor 50a. In the 
former case, the pump 50g could be controlled to maintain a 
predetermined level of fluid within the reservoir, and in the 
latter case the pump 50g could be controlled to maintain a 
predetermined flow through the conduit. Any type of 
conventional feedback control could be used, such as 
proportional -integral (PI) or proportional-integral-derivative 



(PID) control. Where it is desired to control the pump 50g 
based on the output of the level sensor 50h, the association 
of the pump 50g with the level sensor 50h would be stored in 
the configuration file. 

Referring to Fig. 13A, if the operator requested the 
loading of a configuration file at step 2 02, the program 
branches to step 204 where the operator is prompted to select 
one of those configuration files. If the operator did not want 
to retrieve a previously stored configuration file, the program 
branches to step 206, where the operator selects one of a 
predetermined number of types of perfusion circuit images. 
Each perfusion circuit image could correspond to the perfusion 
circuit that would be utilized for a different medical 
procedure. Two different types of perfusion circuit images are 
illustrated in Figs. 14A, 14B described below. 

At step 208, either the perfusion circuit image 
corresponding to the configuration file selected at step 204 
or the perfusion circuit image selected at step 206 is 
displayed on the display 114. A pair of exemplary perfusion 
circuit images that may be displayed on the display 114 are 
illustrated in Figs. 14A and 14B. 

Referring to Fig. 14A, an image 232 of a perfusion circuit 
corresponding to a left ventricle assist device (LVAD) 
configuration is shown. The perfusion circuit image 232 
includes a patient image 234, an image 236 of a fluid conduit 
which removes blood from the left ventricle of the patient, an 
image 23 8 of a pump, an image 24 0 of a fluid conduit which 
returns blood to the aorta of the patient, an image 242 of a 
flow occluder, an image 244 of a temperature sensor, and a pair 
of images 246 of an air embolus sensor. 

Referring to Fig. 14B, an image 248 of a perfusion circuit 
corresponding to a bi-ventricular assist device (Bi-VAD) 
configuration is shown. The perfusion circuit image 248 
includes all of the images shown in Fig. 14A, as well as an 
image 250 of a second blood pump, an image 252 of a conduit 
which removes blood from right ventricle of the patient, and 
an image 254 of a conduit that returns blood to the pulmonary 



artery of the patient. Each of the perfusion circuit images 
illustrated in Figs. 14A, 14B could be pre-stored in the memory 
104 of the main controller 20, in addition to other types of 
perfusion circuit images. 

At step 210, the operator may select one of a number of 
configuration options to change the configuration of the 
perfusion system 10. If the operator selects the option of 
adding a perfusion device 50 as determined at step 212 , the 
program branches to step 214 where the operator is prompted to 
select a type of perfusion device 50, such as a pump or a flow 
sensor, to add to the perfusion circuit image displayed on the 
display 114 . 

At step 216, the operator selects the position at which 
an image of the newly selected perfusion device 50 will be 
displayed. This position could be specified by the operator 
via an electronic mouse, and the displayed perfusion circuit 
image could include a number of possible connection points 256 
(Fig. 14A) at which the perfusion device 50 could be connected. 
The possible connection points 256 could be highlighted, such 
as by placing them in a bold color or making them blink on and 
off, so that the possible connection points 256 are readily 
apparent to the operator. After the operator selects the 
position, at step 218, an image of the perfusion device is 
displayed in the perfusion circuit image at that position. 

If the operator selected the option of configuring one of 
the perfusion devices as determined at step 220, the program 
branches to step 222 where the current configuration of the 
perfusion device 50 is displayed next to the image of the 
device in the perfusion circuit. As noted above, the current 
configuration could include the mode of operation of the 
perfusion device, alarm limits for the device, any associated 
perfusion devices, etc. At step 224, the operator may change 
or add to the current configuration. 

If the operator selected the option of displaying data for 
the perfusion devices as determined at step 226, the program 
branches to step 22 8 where it checks to determine whether there 
is data available to display. Such data could include, for 
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example, the manufacturers and model numbers of the perfusion 
devices. If there is data available as determined at step 228, 
the program branches to step 23 0 where the data is displayed 
next to the perfusion devices in the perfusion circuit. 

5 

Connecting Perfusion Devices 
The main controller 2 0 may utilize a plug- in procedure to 
accommodate perfusion devices 50 that are subsequently 
connected to the perfusion system 10. Fig. 13B is a flowchart 

10 of a plug-in routine 260 performed by the main controller 20. 
During the plug- in routine, the main controller 20 may operate 
in an automatic match mode in which it can match a previously 
entered device configuration with a perfusion device that is 
subsequently connected to the main controller 20. For example, 

15 a operator may configure a centrifugal blood pump (not yet 
connected to the main controller 20) to operate in a continuous 
mode to continuously pump a predetermined flow. When the blood 
pump is subsequently connected to the controller 20, the 
concroller 20 will then automatically match the previously 

2 0 stored pump configuration with the pump. 

Referring to Fig. 13B, at step 262, if the main controller 
20 is in the automatic miatch mode, the program branches to step 
264 where it determines whether there is only one possible 
match between the perfusion device just connected and the 

25 previously stored device configurations. This would be the 
case where there is only one previously stored configuration 
for a pump and where the device that was just connected to the 
main controller 20 was a pump. 

If there was only one possible match as determined at step 

30 264, the program branches to step 266 where it determines 
whether the position at which the device is to be displayed in 
the perfusion circuit image is known. This position could be 
included in the previously stored configuration for the device. 
If the position is not known, the program branches to step 268 

35 where the operator is prompted to select a position, and then 
the program branches to step 270 where an image of the newly 
connected perfusion device is displayed in the perfusion 
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circuit image. If the position of the device as determined at 
step 266 was known, the program skips step 268 and branches 
directly to step 270. 

If the main controller 2 0 was not in the automatic match 
mode, as determined at step 2 62, or if there was more than one 
possible match, as determined at step 264, the program branches 
to step 272. If the newly connected device has already been 
configured, the program branches to step 274 where the operator 
is prompted to select the proper configuration from a plurality 
of prestored configurations. If the device is not already 
configured, the program branches to step 276 where the operator 
enters the desired configuration parameters for the device. 
The program then performs steps 268 and 270 described above. 

Network Communications 
The network controller 106 (Fig. 2) in the main controller 
20, which may be a conventional network controller such as a 
CAN Version 2. OB, oversees the data flow on the network buses 
30, each of which includes the data bus 152 (which may be 
composed of two wires) on which digital data packets are 
transmitted and received. The data packets may have a 
conventional format composed of the following data fields: 1) 
a start-of -frame (SOF) field; 2) an arbitration field; 3) a 
control field; 4) a variable- length data field; 5) an error 
detection/correction field, such as a cyclic-redundancy-check 
(CRC) field; 6) an acknowledgement (ACK) field; and 7) an end- 
of-frame (EOF) field. 

The arbitration field, which may be a 29-bit field, is 
used to determine the priority of the data packets broadcast 
over the network bus 30. The priority is based on the overall 
numeric value of the arbitration field of the data packets. 
In the event of a conflict in the transmission of two data 
packets, the data packet having the arbitration field with a 
lower numeric value takes priority. The arbitration fields, 
which contain a message identification (ID) code specifying the 
type of message, of a number of different data packet types 
that may be used are listed below. 
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Type 


MRSsaae ID (MSB 






A 


00000 


00000000 


CCCCCCCC 


cccccccc 


B 


00000 


00000001 


cccccccc 


cccccccc 


C 


00000 


00000010 


aaaaaaaa 


ssssssss 


D 


00000 


00000100 


cccccccc 


ssssssss 


E 


00001 


CCCCCCCC 


cccccccc 


dddddddd 


F 


00010 


cccccccc 


cccccccc 


ssssssss 


G 


10000 


cccccccc 


dddddddd 


dddddddd 


H 


10001 


cccccccc 


ssssssss 


ssssssss 


I 


mil 


11111111 


11111111 


11111111 


In the 


above table, the 


message 


types are listed from 



highest priority (at the top) to lowest priority (at the 

15 bottom) . The type A message corresponds to a control message 
broadcast by the main controller 20 to all devices attached to 
the network data buses. The data fields '^cccccccc cccccccc" 
are used to specify the type of message. The type B message 
corresponds to a message broadcast by the main controller 20 

20 to the extender controllers 32. The data fields "cccccccc 
cccccccc" are used to specify the type of message. 

The type C message corresponds to an alarm or safety 
message, with the data field "aaaaaaaa" specifying an alarm 
type and the data field "ssssssss" specifying the logical 

2b address of the device which generated the alarm message. The 
type D message corresponds to a servo message generated by a 
sensing device, such as a flow sensor. The data field 
"cccccccc" specifies the type of sensed parameter, e.g. flow, 
and Che data field "ssssssss" specifies the logical address of 

3 0 the sensor that generated the sensed parameter. 

The type E message corresponds to a general message having 
a data field "cccccccc cccccccc" which specifies the type of 
message and a data field "dddddddd" which specifies the logical 
address of the intended destination of the message. The type 

35 F message corresponds to a general message having a data field 
"cccccccc cccccccc" which specifies the type of message and a 
data field "ssssssss" which specifies the logical address of 
the source of the message. 

The type G message corresponds to a general message having 

40 a data field "cccccccc" which specifies the type of message and 
a data field "dddddddd dddddddd" which specifies the physical 
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address of the intended destination of the message. The type 
H message corresponds to a general message having a data field 
"cccccccc" which specifies the type of message and a data field 
"ssssssss ssssssss" which specifies the physical address of the 
source of the message. The type I message (which is all 
logical "l"s) corresponds to a status request from the main 
controller 20 that is periodically broadcast to all devices 
connected to the network data buses. 

Some of the message types described above are transmitted 
without any data fields. For example, the status request 
message from the main controller 20 would not have a data 
field. Other messages would include data fields. For example, 
the servo message (type D above) would include a data field 
which specified the numeric value of the sensed condition, such 
as a flow reading of 0.257 liters per minute. 

The main controller 20, the extender controllers 32, and 
the adapter pods 4 0 may include conventional electronics for 
checking the accuracy of received messages via the CRC field, 
requesting retransmission of messages that were not accurately 
received, and for transmitting acknowledgement messages in 
response to the receipt of accurately received messages. 

The messages described above may be transmitted or 
broadcast to all the devices connected to the network 30. Each 
device, such as a pod 40 or an extender controller 32, can 
discriminate by receiving only certain messages that are 
broadcast. For example, this discrimination could be 

accomplished by accessing a message-discrimination memory in 
the receiving device which stores the logical addresses of all 
other the devices in which the receiving device is interested. 

For example, if the receiving device is the adapter pod 
40c connected to the blood pump 50c which controls the flow of 
blood through a conduit based on receiving a feedback signal 
from the flow sensor 50a, the message-discrimination memory of 
the pod 4 0c would include the logical address of the flow 
sensor 50a, so that the pod 40c would receive any message 
generated by the pod 4 0a connected to the flow sensor 50a. 



The message-discrimination memory would include logical 
address of the main controller 20, and could include the 
logical addresses of a number of other pods 40. Consequently, 
it should be noted that it is not necessary that messages 
broadcast over the network 30 include a specific destination 
address (although a destination address may be included) . 

The pods 4 0 and extender controllers 32 could also 
discriminate messages based on the type of message instead of 
the identity of the sender. For example, a pod 40 could 
receive all status-request messages and configuration messages 
(described below) . The message identification codes for such 
messages could also be stored in the message-discrimination 
memory . 

Before use of the perfusion system 10 for a medical 
procedure, and after all the perfusion devices 50 are 
configured as described above, data packets containing 
configuration messages are transmitted to all the pods 4 0 
connected to the network 30. The configuration messages 
include all the necessary configuration data described above. 
For example, for a blood pump, the configuration data would 
include the operational mode of the pump, the desired flow rate 
of the pump, etc. If any configuration messages which include 
device association data (e.g. the sensor which a blood pump 
should receive feedback from) were received by a pod 40, the 
message-discrimination memory would be updated with the logical 
address of the associated device. 

Connecting Pods to the Network 
In order for them to communicate with the main controller 
2 0 via the network data/power buses 30, the adapter pods 4 0 
must be granted permission to connect to the network 30. This 
connection is initiated with a startup-request message 
transmitted to the main controller 20 by the adapter pod 4 0 for 
which the network connection is to be made. The startup- 
request message includes a first code identifying the type of 
perfusion device 50 connected to the pod 4 0 requesting to be 
connected and a second code identifying the physical address 
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(specified by the code generator 144 of Fig. 11) of the pod 40 
requesting to be connected. 

Fig. 13C is a flowchart of a startup routine 280 that is 
performed by the main controller 20 in response to the receipt 
of a startup-request message from an adapter pod 40. The 
startup routine 280 may be an interrupt service routine which 
is invoked in response to an interrupt generated upon the 
receipt of a startup-request message by the main controller 20. 
Referring to Fig. 13C, at step 282, the startup message 
received by the main controller 20 is decoded to determine the 
type of the perfusion device 50 attached to the pod 40 
requesting to be connected and to determine the physical 
address of the pod 40. 

At step 284, the program determines whether full power 
should be granted to the requesting pod 40. As described 
above, electrical power to run the perfusion devices 50 is 
provided to the pods 4 0 via the network 3 0 from a power supply 
118 (Fig, 9) in the main controller 20. Since the power 
available from the power supply 118 may be limited, the main 
controller 2 0 may be programmed to allow only a certain number 
of perfusion devices 50 to be connected to the network 30, or 
alternatively, to allow only certain numbers of specific types 
of perfusion devices 5 0 to be connected. For example, since 
control devices such blood pumps typically draw more power than 
sensing devices, the main controller 20 may be provided with 
an upper limit on the number of control devices that can be 
connected to the network 30. 

At step 284, the decision whether to grant full power 
could be made by comparing the number of perfusion devices 50 
already connected to the network 3 0 with the maximum number 
that can be connected to determine whether the connection of 
an additional device 50 will cause the maximum to be exceeded. 
Alternatively, if the device requesting connection is a control 
device, then the number of control devices already connected 
could be compared with the maximum number of control -type 
perfusion devices that can be connected. If it is determined 
that full power should not be granted, the program simply ends. 
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If it is determined that full power should be granted, 
steps 286-298 are performed to generate and transmit a startup 
granted message that will cause the pod 4 0 associated with the 
perfusion device 50 to be connected to the network 30. In 
particular, at step 286, a unique logical address is allocated 
to the newly connected pod 40. For example, where the capacity 
of the network 30 is sixteen devices, the logical address may 
be a four-bit binary code. At step 288, a startup-granted 
message which includes the logical address is encoded, and at 
step 290 the startup-granted message is transmitted over the 
network 30. 

At step 292, if the pod 40 which requested startup is 
local to the main controller 20 (i.e. if it is one of the pods 
40g or 40h directly connected to the main controller 20 without 
a network extender 22) , full power to the pod 40 is enabled via 
the local node controller (i.e. one of the node controllers 
34i-34j of Fig. 9) connected to the perfusion device 50. 
Referring to Fig. 11, this is accomplished by sending an enable 
signal on the line 134, which will cause the controller 140 to 
close the switches 150, 154, 158 so that full power is supplied 
on the power lines 12 0a, 12 0b and so that the adapter pod 4 0 
is connected to the data bus 152. 

Referring to Fig. 13C, if the perfusion device was not a 
local device as determined at step 292, the program branches 
to step 2 96 where a connect message which includes the physical 
address of the node controller 34 associated with the pod 40 
requesting startup is encoded, and then to step 298 where the 
connect message is transmitted over the network 30. As 
described below, when the extender controllers 32 receive the 
connect message, they decode it to determine the physical 
address, and the extender controller 32 connected to the node 
controller 34 having that physical address (i.e. the node 
controller 34 associated with the requesting pod 40) turns on 
full power by transmitting an enable signal on the line 134 
connected to that node controller. 



Status Requests 
During operation of the perfusion system 10, to ensure 
that all devices connected to the network 3 0 are properly 
functioning and are receiving messages broadcast over the 
network 30, the main controller 20 periodically transmits a 
status-request message to all extender controllers 32 and 
adapter pods 40 on the network 30. Each extender controller 
32 and adapter pod 40 must respond to the status request within 
a predetermined period of time. Any extender controller 32 or 
pod 4 0 that fails to respond to the status request within that 
time period is disconnected from the network 30, and a 
corresponding alarm message is generated on the visual display 
114 to warn the operator of such event. 

Fig. 13D is a flowchart of a status-request routine 300 
periodically performed by the main controller 20. Referring 
to Fig. 13D, at step 302 a status-request message is encoded, 
and at step 3 04 the message is broadcast to all extender 
controllers 32 and adapter pods 40 connected to the network 30. 
As described above, the status -request message may simply be 
all logical "l"s in the arbitration of the data packet. At 
step 306, a predetermined time-out period within which all 
extender controllers 3 2 and pods 4 0 must respond to the status 
request message is started. 

Upon receiving the status -request message, each extender 
controller 32 and adapter pod 4 0 encodes a status message with 
its logical address and its status, and then broadcasts the 
status message to the main controller 20 over the network 30. 

Fig. 13E is a flowchart of a receive status routine 310 
that is performed by the main controller 20 upon receipt of a 
status message transmitted to it in response to the status- 
request message previously transmitted by the routine 300. 
Referring to Fig. 13E, at step 312 the logical address of the 
responding extender controller 3 2 or adapter pod 4 0 is 
determined from the status message, and at step 314 the status 
of the device 32 or 40 is determined from the message. The 
status may be specified by a number of different binary status 
codes. At step 316, if the status of the device 32 or 40 is 
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okay, the program simply ends. However, if the status is not 
okay, the program branches to step 318 where it responds to a 
status condition identified by the status code. If the 
condition is relatively minor, the main controller 2 0 may 
simply generate a warning on the visual display 114 of the 
perfusion system 10. If the condition is serious enough, the 
main controller 20 may disconnect the device 32 or 40 from the 
network 30. 

Fig. 13F is a flowchart of a disconnect routine 33 0 that 
causes an extender controller 3 2 or an adapter pod 4 0 to be 
disconnected from the network 30. The disconnect routine 330 
is performed by the main controller 20 in response to either: 
1) the failure of a device 32 or 40 to transmit a status 
message to the main controller 20 within the timeout period 
15 described above or 2) a serious malfunction of a device 32 or 
40 as determined at step 318 of Fig. 13E. 

Referring to Fig. 13F, at step 332, if the device 32 or 
40 to be disconnected is local to the main controller 20, the 
program branches to step 334 where that device 32 or 40 is 
20 disconnected by the node controller 34g, 34h, 34i, or 34 j in 
the main controller 20 that is connected to that device 32 or 
40. Referring to Fig. 11, the disconnection is accomplished 
by transmitting a disable signal on the line 134, which will 
cause the controller 140 to open the switches 150, 154, 158 so 
25 that the data bus 152 and the power lines 120a, 120b are 
disconnected . 

At step 332, if the device to be disconnected is not local 
to the main controller 20, the program branches to step 336 
where a disconnect message which includes the physical address 
of the node controller 34 of the device 32 or 40 to be 
disconnected is encoded, and then to step 3 38 where the 
disconnect message is transmitted over the network 30. 

If the device to be disconnected is a pod 40 connected to 
an extender controller 32 via a node controller 34, when that 
35 extender controller 32 receives the disconnect message, it 
decodes it to determine the physical address of the pod 4 0 to 
be disconnected, and the node controller 34 associated with 
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that pod 40 disconnects the pod 40 by transmitting a disable 
signal on the line 134 connected to that node controller 34. 



Operator Commands Input to M ain Controller 
5 During operation of the perfusion system 10 during a 

medical procedure, the main controller 20 responds to various 
commands and other inputs entered by the operator of the system 
10. Fig. 13G is a flowchart of a control command routine 3 50 
which illustrates how the main controller 20 responds to those 

10 inputs. While Fig. 13G discloses various possible operator 
inputs, it should be understood that the main controller 20 
could respond to other or additional operator inputs. 

Referring to Fig. 13G, at step 352, if the input entered 
by the operator was a control command, the program branches to 

15 step 3 54 where a control message corresponding to the control 
command is encoded in a data packet, and then to step 3 56 where 
the control message is broadcast over the network 30 . For 
example, the control message could be one of the following: 
1) a new alarm limit for a particular sensing device; 2) a new 

2 0 mode of operation for a blood pump; 3) a new target flow value 

for a blood pump; 4) a new rate at which a particular sensing 
device should be read; 5) a pump start command; 6) a pump 
stop command; etc. 

At step 358, if the operator requests that a particular 
25 alarm be reset, the program branches to step 360 where a 
corresponding alarm-reset message, which includes the logical 
address of the device that generated the alarm, is encoded and 
to step 362 where the alarm-reset message is broadcast over the 
network 30. At step 364, if the operator requests that the 

3 0 perfusion system 10 be reset, the program branches to step 366 

where a corresponding system reset message is encoded and to 
step 362 where the system reset message is broadcast over the 
network 30. 
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Receipt of Network Messages bv Main Controller 
During operation, the main controller 20 receives messages 
of various types that are broadcast over the network 30. Fig. 



13H is a flowchart of a receive routine 3 70 performed by the 
main controller 20 that illustrates actions taken by the main 
controller 20 in response to the receipt of various types of 
messages . 

Referring to Fig. 13H, at step 372, if the received 
message corresponds to an event message, such as an alarm or 
other event, the program branches to step 3 74 where the visual 
display generated on the display device 114 is updated to 
advise the operator of that event, and the program branches to 
step 3 76 where the event is logged into an event log stored in 
the memory 104 of the main controller 20. 

At step 378, if the received message corresponds to a data 
message, such as a message which includes the numeric value 
representing the output of a flow sensor, the program branches 
to step 380 where the visual display is updated, and the 
program branches to step 3 82 where the data and the device 
which generated the data are logged into a data log stored in 
the memory 104 of the main controller 20. 

At step 384, if the received message is a status message, 
the program branches to step 386 where the status message is 
processed, as described above in connection with Fig, 13E. At 
step 3 88, the visual display is updated based on the status, 
and at step 390 the status is stored in a status log stored in 
memory. At step 3 92, if the received message is a startup 
request, the program branches to step 3 94 where the startup 
request is processed, as described above in connection with 
Fig. 13C, and at step 396, the visual display is updated. 

Operation of Extender Controllers 
A basic function of the extender controllers 32 is to 
control the connection and disconnection of adapter pods 4 0 to 
the network 30. Fig. 15A is a flowchart of a startup routine 
420 performed by the controller 130 of each extender controller 
32. Referring to Fig. ISA, at step 422 the extender controller 
32 performs a number of internal self -tests, such as tests of 
an internal RAM and an internal ROM. At step 424, if the tests 
were successful, the program branches to step 426 where the 
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connection of the extender controller 32 to the network bus 3 0 
is tested by transmitting a message onto the network bus 3 0 and 
simultaneously receiving the message from the network bus 30 
as it is transmitted to determine if the message was in fact 
5 transmitted. 

At step 428, if the data bus test was successful, the 
program branches to step 43 0 where the extender controller 32 
starts to periodically transmit a check-in code to its parent 
node controller 34 via the line 133 . As described below, each 

10 device (either an adapter pod 40 or an extender controller 32) 
must periodically transmit a check- in code to its parent node 
controller 34 to maintain its connection to the network 30. 

At step 432 , the extender control ler 32 waits for its 
physical address to be transmitted to it from its parent node 

15 controller 34. At step 434, if not all of the tests performed 
at steps 422 and 426 were passed, an error message is broadcast 
over the network 30, The error message includes the physical 
address of the extender controller 32 and a binary code which 
specifies which test(s) were not passed. 

20 If all tests were passed, the program branches to step 438 

where a startup-request message containing the physical address 
of the extender controller 32 is encoded and broadcast over the 
network 30. At step 440, the program waits until a startup- 
granted message is received from the main controller 20, and 

25 then at step 442 the program waits until full power is granted 
to the extender controller 32 via the electrical power lines 
120a, 120b of its parent node controller 34. When full power 
is granted, the program branches to step 444 where the extender 
controller 3 2 measures the voltages on and the current provided 

3 0 by the electrical power lines 12 0a, 12 0b to make sure they are 
within specification. At step 446, if the power measurements 
are not within specification, the program branches to step 436 
where a message to that effect is broadcast to the main 
controller 20 over the network 30. 

35 Fig. 15B is a flowchart of a connect routine 450 performed 

by an extender controller 3 2 when it receives a connect message 
from the main controller 20. Referring to Fig. 15B, at step 



452, the connect message received from the main controller 20 
is decoded to determine the physical address of the adapter pod 
40 to be connected to the network 30. At step 454, the 
physical address is inspected to determine if the adapter pod 
40 to be connected is local to the extender controller 32, 
meaning that the adapter pod 40 is one of the three that are 
connected to the extender controller 32. If the pod 40 is not 
local to the extender controller 32, no further action is taken 
and the routine 450 ends. If the pod 40 is local to the 
extender controller 32, the program branches to step 456 where 
an enable signal is transmitted via one of the lines 134 to the 
node controller 34 associated with the adapter pod 40 to be 
connected, which causes the adapter pod 4 0 to be connected to 
the network 3 0 in the manner described above. 

When an extender controller 32 receives a disconnect 
message from the main controller 20, a disconnect routine 460 
shown in Fig. 15C is performed by the extender controller 32. 
Referring to Fig. 15C, at step 462, the disconnect message 
received from the main controller 2 0 is decoded to determine 
the physical address of the adapter pod 40 to be disconnected 
to the network 30. At step 464, the physical address is 
inspected to determine if the adapter pod 4 0 to be disconnected 
is local to the extender controller 32. If the pod 40 is not 
local, no further action is taken. If the pod 40 is local, the 
program branches to step 4 66 where a disable signal is 
transmitted via one of the lines 134 to the node controller 34 
associated with the adapter pod 4 0 to be disconnected, which 
causes the adapter pod 40 to be disconnected to the network 30. 

Operation of Node Controllers 
The basic function of the node controllers 34 is to 
connect and disconnect the adapter pods 4 0 (if a node 
controller 34 is the parent of an adapter pod 40) and the 
extender controllers 32 (if a node controller 34 is the parent 
of an extender controller 32) from the network 30. The 
connection or disconnection is performed pursuant to an enable 
or disable signal received either from the main controller 20 



or from the extender controller 32 associated with the node 
controller 34, as described above. In addition, each node 
controller 34 requires its associated device 32 or 40 to 
periodically check-in. If the device 32 or 40 fails to check 
in with a proper check- in code, the node controller 34 
disconnects the device 32 or 40 from the network 30. 

Fig. ISA is a flowchart of a node routine 4 70 performed 
by each of the node controllers 34. The routine 470 is 
performed upon the receipt by the node controller 34 of a 
check-in code received from the associated device 32 or 40. 
Referring to Fig. 16A, at step 472, if the code received from 
the device 32 or 40 is not valid, no further action is taken 
and the routine ends. The check-in code may be the physical 
address specified by the code generator 144 (Fig. 11) of the 
node controller 34. To determine whether the code is valid, 
the node controller 34 may compare the received code to 
determine whether it matches a predetermined code. 

If the check- in code was valid, the program branches to 
step 474 where a time-out timer is restarted. The time-out 
timer tracks the predetermined period of time within which the 
device 32 or 40 must transmit a valid check-in code. A.t step 
476, the node controller 34 transmits the physical address 
generated by the code generator 144 to the pod 40. At step 
478, the node controller 34 connects the device 32 or 40 to the 
data bus 152 (Fig. 11) by sending a signal to the switch 150 
which causes it to close (or remain closed if it was already 
closed) . 

At step 480, if the enable signal is present on the line 
134 connected to the node controller 34, the node controller 
34 supplies full power to the device 32 or 40 by sending 
signals to the switches 154, 158 (Fig. 11) to cause them to 
close (or remain closed if they were already closed) . 

If the enable signal was not present as determined at step 
480, the program branches to step 4 84, where the device 32 or 
40 is disconnected from the data bus 152 by opening the switch 
150 and to step 484 where the device 32 or 40 is disconnected 
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from the electrical power lines 120a, 120b by opening the 
switches 154, 158. 

If the device 32 or 40 fails to transmit a valid check-in 
code to the node controller 34 within the time-out period, a 
5 time-out routine 490 shown in Fig. 16B is performed by the node 
controller 34. Referring to Fig. 16B, at step 492 the device 
32 or 4 0 is disconnected from the data bus 152 by opening the 
switch 150, and at step 494 the device 32 or 40 is disconnected 
from the electrical power lines 12 0a, 12 0b by opening the 
10 switches 154, 158. 

Operation of Adapter Pods 
The adapter pods 4 0 perform a number of functions, 
including receiving configuration and control messages 

15 transmitted by the main controller 20, receiving sensing 
messages containing numeric values of sensed conditions, such 
as flow, and/or transmitting sensing messages over the network 
30. These functions are described below. 

Fig. 17A is a flowchart of a startup routine 520 performed 

20 by the controller 180 of each adapter pod 40. Referring to 
Fig. 17A, at step 522 the adapter pod 40 performs a number of 
internal self -tests, such as tests of an internal RAM and an 
internal ROM. At step 524, if the tests were successful, the 
program branches to step 526 where the connection of the pod 

25 40 to the data bus 152 is tested by transmitting a message onto 
the data bus 152 and simultaneously receiving the message from 
the data bus 152 as it is transmitted to determine if the 
message was in fact transmitted. 

At step 528, if the data bus test was successful, the 

3 0 program branches to step 53 0 where the adapter pod 4 0 starts 
to periodically transmit a check- in code to its parent node 
controller 34 via the line 133. At step 532, the pod 40 waits 
for its physical address to be transmitted to it from its 
parent node controller 34. At step 534, if not all of the 

35 tests performed at steps 522 and 526 were passed, an error 
message is broadcast over the network 30. The error message 
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includes the physical address of the pod 40 and a binary code 
which specifies which test(s) were not passed. 

If all tests were passed, the program branches to step 538 
where a startup-request message containing the physical address 
of the adapter pod 4 0 is encoded and broadcast over the network 
30. At step 540, the program waits until a startup-granted 
message is received from the main controller 20, and then at 
step 542 the program waits until full power is granted to the 
adapter pod 40 via the electrical power lines 120a, 120b of its 
parent node controller 34. When full power is granted, the 
program branches to step 544 where the pod 4 0 measures the 
voltages on and the current provided by the electrical power 
lines 120a, 120b to make sure they are within specification. 
At step 546, if the power measurements are not within 
specification, the program branches to step 536 where a message 
to that effect is broadcast to the main controller 20 over the 
network 30. 

During operation, an adapter pod 40 may receive control 
or configuration messages from the main controller 20 over the 
network. Fig. 17B is a flowchart of a receive routine 550 that 
is performed when the adapter pod 40 receives a message. 
Referring to Fig. 17B, at step 552 the message is decoded to 
determine the control command embedded in the message, and at 
step 554, the pod 4 0 transmits a control signal (via one or 
more of the data lines 192 in Fig. 12) to the perfusion device 
50 connected to it. 

During operation, an adapter pod 4 0 may receive an alarm 
signal from the perfusion device 50 via one of the data lines 
192. When such an alarm signal is received, an alarm routine 
560 shown in Fig. 17C is performed by the pod 40. Referring 
to Fig. 17C, at step 562 an alarm message is encoded with the 
logical address of the perfusion device 50 that generated the 
alarm and the type of alarm, and at step 564 the alarm message 
is broadcast over the network 30 to the main controller 20. 

During operation, each adapter pod 4 0 connected to a 
perfusion device 50, such as a flow sensor, which generates a 
sensing signal periodically reads the numeric value of the 



sensing signal via one of the lines 152. The time period 
between successive readings of the sensing signal may be 
specified during the configuration process as described above. 
Fig. 17D is a flowchart of a sensing routine 570 that is 
performed when it is time to read the value of the sensing 
signal. Referring to Fig. 17D, at step 572 the sensing signal 
is read via one of the data lines 152. At step 574, the 
numeric value of the sensing signal is encoded in a message 
along with the logical address of the perfusion device 50 which 
generated the sensing signal. At step 576, that message is 
then broadcast over the network 3 0 to all devices connected to 
the network 30. 

As described above, each adapter pod 4 0 connected to the 
network 3 0 may be provided with a message -discrimination 
circuit which is used to selectively receive messages from only 
a subset of the devices connected to the network 30. When the 
sensing message is broadcast at step 576, the only devices that 
receive it are the main controller 20 (which may receive all 
messages broadcast over the network 30) and the particular 
perfusion device 50 which is being controlled based on the 
value of the sensing signal encoded in the sensing message. 

It should be understood that the adapter pods may be 
provided with additional functionality not described above. 
Also, instead of having electrical power being distributed over 
the network from a single power source provided in the main 
controller 20, electrical power could be distributed from a 
plurality of power sources, for example, from one power source 
provided in each of the network extenders . 

Since numerous additional modifications and alternative 
embodiments of the invention will be apparent to those skilled 
in the art in view of the foregoing description, the above 
description is to be construed as illustrative only, and is for 
the purpose of teaching those skilled in the art the best mode 
of carrying out the invention. The details of the structure 
may be varied substantially without departing from the spirit 
of the invention, and the exclusive use of all modifications 
which come within the scope of the appended claims is reserved. 
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WHAT IS CLAIMED IS: 

/ 

1. A medical perfusion system for use in connection with 
the medical treatment of a patient, comprising: 
5 a first blood pump adapted to pump blood through a first 

conduit fluidly connected to the patient; 

a second blood pump adapted to pump blood through a second 
conduit fluidly connected to the patient; 

a first sensor for sensing a first condition relating to 
10 the pumping of blood through said first conduit, said first 
sensor generating a sensing signal relating to said first 
condition; 

a second sensor for sensing a conaition relating to the 
pumping of blood through said second conduit, said second 
15 sensor generating a sensing signal relating to said second 
condition; 

a data communications network for operatively 
interconnecting said blood pumps and said sensors, said data 
communications network having a plurality of network 
2 0 connectors, each of said network connectors having an identical 
connector configuration; 

a first adapter pod having a com.mon connector and a device 
connector, said common connector being adapted to be coupled 
to one of said network connectors and said device connector 
25 being adapted to be coupled to said first pump; 

a second adapter pod having a common connector and a 
device connector, said common connector of said second adapter 
pod being adapted to be coupled to one of said network 
connectors and said device connector of said second adapter pod 
30 being adapted to be coupled to said second pump; 

a third adapter pod having a common connector and a device 
connector, said common connector of said third adapter pod 
being adapted to be coupled to one of said network connectors 
and said device connector of said third adapter pod being 
35 adapted to be coupled to said third pump; 

a fourth adapter pod having a common connector and a 
device connector, said common connector of said fourth adapter 
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pod being adapted to be coupled to one of said network 
connectors and said device connector _of said fourth adapter pod 
being adapted to be coupled* to~ said^ fourth pumpy said device 
connector of said fourth adapter pod having a different 
5 structure than said device connector of said first adapter pod; 

means for transmitting messages in the form of digital 
data packets among said first and second blood pumps and said 
first and second sensors over said data communications network; 
and 

10 a controller operatively coupled to said blood pumps and 

said sensors via said data communications network, said 
controller having an input device for accepting pump control 
commands relating to said first and second blood pumps from an 
operator . 

15 

2. A system as defined in claim 1 wherein said device 
connector of said fourth adapter pod has a first number of 
signal lines and wherein said common connector of said fourth 
adapter pod has a second number of signal lines different than 

20 said first number. 

3. A system as defined in claim 1 wherein said means for 
transmitting messages comprises: 

means for generating a message containing a control 
25 command for one of said pumps; and 

means for generating a message containing data relating 
to one of said first and second conditions. 

4. A system as defined in claim 1 wherein each of said 
30 adapter pods comprises means for generating a message in the 

form of a digital data packet. 

5. A system as defined in claim 1 wherein said 
controller includes a plurality of network connectors and 

35 wherein said data communications network includes a network 
extender comprising : 
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a network connector adapted to be operatively coupled to 
one of said network connectors of said controller; 

a plurality of extender connectors adapted to be connected 
to said common connectors of said adapter pods; and 
5 a data bus electrically interconnecting said network 

connector of said network extender with each of said extender 
connectors . 

6. A system as defined in claim 1 wherein said 
10 controller additionally comprises a network ^controller for 

controlling transmission of said messages over said data 
communications network , 

7. A medical perfusion system for use in connection with / 
15 the medical treatment of a patient, comprising: 

a first type of perfusion device, said first type of 
perfusion device comprising a blood pump being adapted to pump 
blood through a fluid conduit connected to the patient; 

a second type of perfusion device, said second type of 
20 perfusion device being adapted to sense a condition relating 
to the pumping of blood through said fluid conduit, said second 
type of perfusion device generating a sensing signal relating 
to said condition; 

a data communications network for operatively 
25 interconnecting said first type of perfusion device and said 
second type of perfusion device, said data communications 
network having a plurality of network connectors, each of said 
network connectors having an identical connector configuration; 

a first adapter pod having a common connector and a device 
3 0 connector, said common connector being adapted to be coupled 
to one of said network connectors and said device connector 
being adapted to be coupled to said blood pump; 

a second adapter pod having a common connector and a 
device connector, said common connector of said second adapter 
3 5 pod being adapted to be coupled to one of said network 
connectors and said device connector of said second adapter pod 
being adapted to be coupled to said second type of perfusion 
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device, said device connector of said second adapter pod having 
a different structure than said device connector of said first 
adapter pod; 

means for transmitting messages in the form of digital 
5 data packets among said perfusion devices over said data 
communications network; and 

a controller operatively coupled to said perfusion devices 
via said data communications network, said controller having 
an input device for accepting pump control commands relating 
10 to said blood pump from an operator. 

8. A system as defined in claim 7 wherein said device 
connector of said first adapter pod has a first number of 
signal lines and wherein said common connector of said first 

15 adapter pod has a second number of signal lines different than 
said first number. 

9. A system as defined in claim 7 wherein said means for 
transmitting messages comprises: 

20 means for generating a message containing a control 

command for said pump; and 

means for generating a message containing data relating 
to said condition. 

25 10. A system as defined in claim 7 wherein each of said 

adapter pods comprises means for generating a message in the 
form of a digital data packet, 

11. A system as defined in claim 7 wherein said 
30 controller includes a plurality of network connectors and 
wherein said data communications network includes a network 
extender comprising: 

a network connector adapted to be operatively coupled to 
one of said network connectors of said controller; 
3 5 a plurality of extender connectors adapted to be connected 

to said common connectors of said adapter pods; and 



a data bus electrically interconnecting said network 
connector of said network extender with each of said extender 
connectors . 

12. A system as defined in claim 7 wherein said 
controller additionally comprises a network controller for 
controlling transmission of said messages over said data 
communicat ions network . 

13. A medical perfusion system for use in connection with 
the medical treatment of a patient, comprising: 

a first type of perfusion device, said first type of 
perfusion device comprising a blood pump being adapted to pump 
blood through a fluid conduit connected to the patient; 

a second type of perfusion device , said second type of 
perfusion device being adapted to sense a condition relating 
to the pumping of blood through said fluid conduit, said second 
type of perfusion device generating a sensing signal relating 
to said condition; 

a data communications network for operatively 
interconnecting said first type of perfusion device and said 
second type of perfusion device, said data communications 
network having a plurality of network connectors and a network 
extender comprising : 

a network connector adapted to be operatively 

coupled to one of said network connectors of said 

controller; 

a plurality of extender connectors adapted to be 
connected to said common connectors of said adapter pods; 
and 

a data bus electrically interconnecting said network 
connector of said network extender with each of said 
extender connectors; 

means for transmitting messages in the form of digital 
data packets among said perfusion devi'ces over said data 
communications network; and 



a controller operatively coupled to said perfusion devices 
via said data communications network, said controller having 
an input device for accepting pump control commands relating 
to said blood pump from an operator. 

14. A system as defined in claim 13 wherein said means 
for transmitting messages comprises: 

means for generating a message containing a control 
command for said pump; and 

means for generating a message containing data relating 
to said condition. 

15. A system as defined in claim 13 wherein said 
controller additionally comprises a network controller for 
controlling transmission of said messages over said data 
communications network . 

16 . An adapter pod for use in a medical perfusion system 
having a data communications network with a plurality of 
connection points each having a substantially identical network 
connector, said adapter pod comprising: 

a common connector adapted to be connected to one of said 
network connectors, said common connector having a connector 
conf igurat ion ; 

a device connector adapted to be connected to a perfusion 
device, said device connector having a connector configuration 
different than said connector configuration of said common 
connector; and 

means for generating a message in the form of a digital 
data packet . 

17. An adapter pod as defined in claim 16 wherein said 
device connector has a first number of signal lines and wherein 
said common connector has a second number of signal lines 
different than said first number. 



- 36 - 

MEDICAL PERFUSION SYSTEM 

Abstract of the Disclosure 
A medical perfusion system for use in connection with the 
5 medical treatment of a patient is provided with a first type 
of perfusion device in the form of a blood pump adapted to pump 
blood through a fluid conduit connected to the patient, a 
second type of perfusion device in the form of a sensor adapted 
to sense a condition rStlating to the pumping of blood through 

10 the fluid conduit and to generate a sensing signal relating to 
the condition, and a data communications network for 
cperatively interconnecting the perfusion devices. The 
perfusion system also includes means for transmitting messages 
in the form of digital data packets among the perfusion devices 

15 over the data communications network and a controller 
operatively coupled to the perfusion devices via the data 
communications network, the controller having an input device 
for accepting pump control commands relating to the blood pump 
from an operator. 






V) 


•a 
-J 

O 










2o 



7\ 




//Z 



7\ 




34j 



3o^ 



//4 



F/C. 7 



133 




30o 




CUD 



40(x. 

k 



DATA 



-f24V ^SV'SWO 




r 



/90 /<: 



I20c 



/F2. 




DISPLAY 
PERFUSION CIRCUIT 



SELECT OPTION 



208 



210 




SELECT 
DEVICE TYPE 



DISPLAY CURRENT 
CONFIGURATION 



216 



224 



SELECT POSITION 



CHANGE 
CONFIGURATION 



I 



DISPLAY DEVICE 
IN PERFUSION 
CIRCUIT 



218 



226 




DISPLAY 
DATA 



END 



FIG. 13A 




SELECT POSITION 






■< 


DISPLAY DEVICE IN 
PERFUSION CIRCUIT 



END J 



c 



DECODE DEVICE 
TYPE AND PHYSICAL 
ADDRESS 




ALLOCATE LOGICAL 
ADDRESS 



2^4 



Y , 



ENCODE STARTUP 
GRANTED MESSAGE 



TRANSMIT MESSAGE 



29 Z. 




ENABLE POWER VIA 
LOCAL NODE 
CONTROLLER 



ENCODE NODE ENABLE 
MESSAGE 



I 



TRANSMIT MESSAGE 



29^ 



fl6, I3C 



END J 



STATUS 
REQUEST 



ENCODE STATUS 
REQUEST MESSAGE 



I 



BROADCAST STATUS 
REQUEST MESSAGE 



START TIME-OUT 
PERIOD 



300 



302 



304 



306 



330 



I 



END 




FIG. 13D 



310 



Yes 



334 



DISCONNECT VIA LOCAL 
NODE CONTROLLER 



RECEIVE STATUS ; 



336 



DETERMINE LOGICAL ADDRESS 
FROM STATUS MESSAGE 



312 



ENCODE 
DISCONNECT MESSAGE 



338 



DETERMINE STATUS 
FROM MESSAGE 



314 



TRANSMIT MESSAGE 




Yes 
318 



RESPOND TO 
STATUS CONDITION 



END 



FIG. 13F 



END 



FIG. 13E 




ENCODE CONTROL 
MESSAGE 



I 



BROADCAST 
CONTROL MESSAGE 




ENCODE ALARM 
RESET MESSAGE 



BROADCAST ALARM 
RESET MESSAGE 



354 



356 



360 



362 




ENCODE SYSTEM 
RESET MESSAGE 



366 



FIG. 13G 



BROADCAST SYSTEM 
RESET MESSAGE 



368 



END 



370 




LOG 
EVENT 



376 



LOG 
DATA 



382 



UPDATE 
DISPLAY 



388 



UPDATE 
DISPLAY 



396 



FIG. 13H 



LOG 
STATUS 



^ 

390 



EXTENDER STARTUP^^ 



420 



PERFORM INTERNAL 
SELF-TESTS 



BROADCAST 
ERROR 
MESSAGE 



436 



422 




426 



START PERIODIC 
TRANSMISSION TO 
NODE CONTROLLER 



430 



WAIT FOR 
PHYSICAL ADDRESS 



432 




434 



BROADCAST 
STARTUP REQUEST 



1 



WAIT FOR STARTUP 
GRANTED MESSAGE 



438 



440 



WAIT FOR 
FULL POWER 



442 



MEASURE VOLTAGES 
AND CURRENT 




444 



446 



FIG. 15A 



DECODE PHYSICAL 
ADDRESS OF MESSAGE 




TRANSMIT ENABLE 
SIGNAL TO NODE 
CONTROLLER 



END J 



DECODE PHYSICAL 
ADDRESS OF MESSAGE 



U>2. 




( 



TRANSMIT DISABLE 
SIGNAL TO NODE 
CONTROLLER 






■< 

r 



END 



FI6, /SB 



/so 



r NODE J) 




RESTART 
TIME-OUT TIMER 



476 



TRANSMIT PHYSICAL 
ADDRESS 



478 



CONNECT Oe\//C£ 
TO DATA BUS 




SUPPLY FULL 
POWER TO D^mcB 



484 



DISCONNECT OfviCE 
FROM DATA BUS 



490 



c 



TIME-OUT 



DISCONNECT O^^^'C^ 
FROM DATA BUS 



DISCONNECT Pev/c£. 
FROM FULL POWER 



c 



END 



FIG. 16B 



^486 



DISCONNECT DEVICE- 
FROM FULL POWER 



END ^ 



FIG. 16A 



550 



c 



POD STARTUP 



RECEIVE 



522 



PERFORM INTERNAL 
SELF-TESTS 



DECODE MESSAGE 



524 



526- 




552 



554 



TRANSMIT CONTROL 
SIGNAL TO DEVICE 



c 



I 



END 



FIG. 17B 



560 



530 



BROADCAST 
ERROR 
MESSAGE 



START PERIODIC 
TRANSMISSION TO 
NODE CONTROLLER 



562- 



ALARM 



ENCODE ALARM 
MESSAGE 



WAIT FOR 
PHYSICAL ADDRESS 



532 



536 




BROADCAST 
ALARM MESSAGE 



564- 



c 



I 



END 



538 



540 



542 



544- 



BROADCAST 
STARTUP REQUEST 



570 



WAIT FOR STARTUP 
GRANTED MESSAGE 



WAIT FOR 
FULL POWER 



I 



MEASURE VOLTAGES 
AND CURRENT 



572 



574 



576 



FIG. 170 



SENSE 



READ SENSING 
SIGNAL 



I 



ENCODE MESSAGE 
WITH SENSING 
SIGNAL 




I 



BROADCAST 
MESSAGE 



END 



FIG. 17A 



c 

FIG. 17D 



Docket No. 52863USA4A 



DECLARATION, POWER OF ATTORNEY, AND PETITION 



I, a bdow named inventor, dqpose and say that: (1) residence, citizenship, and mailing 
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Nazarian, Dirk Smith, James R Watts, Richard A. Griewski, and I are the original, first, and joint 
inventors or discoverers of the invention or discovery in 



described and claimed therein and for which a patent is sought; and (4) I hereby acknowledge my duty to 
disclose to the Patent and Trademaik Office all information known to me to be material to the 
patentability as defined in Title 37, Code of Federal Regulations, §1.56.* 

I hereby appoint Gaiy L. Griswold (Reg. No. 25,396), Walter N, Kim (Reg. No. 21,196), Tcnyl 
K. C^cy (Reg. No. 25,148), Warren R. Bovee ^g. No. 26,434), Gerald F. CSiemivec (Reg. No. 26,53'^, 
Douglas B. Little (Eleg. No. 28,439), David R. Qeveland (Reg. No. 29,524), Stephen W. Bauer (Reg. No. 
32,192), and Martin J. IBrsch, (Reg. No. 32,237) my attorneys and/or agents with fiill powers (including 
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continuation, continuation-in-part, reexamination, or reissue thereof, and to transact all business in the 
Patent and Trademaik Office connected therewith; the mailing address and the telephone number of the 
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Attention: Stephen W. Bauer 

3M Office of Intelledual Property Counsel 

P.O. Box 33427 

St Paul, Minnesota 55133-3427 

Telephone No. (612) 733-1500 
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are true and that all statements made on information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and the like so made are 
punishable by fine or imprisonment, or both, under Section 1001 of Titie 18 of the United States Code and 
that such willful false statements may jeopardize the validity of the application or any patent issuing 
thereoit 

Wherefore, I pray for grant of Letters Patent for the invention or discovery described and claimed 
in the aforementioned specification and I hcnSby subscribe my name to the foregoing specification and 
claims, declaration, power of attorney, and this petition, on the day set forth below. 
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§L56 Duty to disclose iaformation material to patentability. 

(a) A patent by its veiy nature is affected with a public interest The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of all information nfiaterial to patentability. Each individual 
associated with the filing and prosecution of a patent application has a duty of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that 
individual to be material to patentability as defined in this section. The duty to disclose information exists 
with respect to each pending claim until the claim is cancelled or withdrawn fh>m consideration, or the 
application becomes abandoned Information material to the patentability of a claim that is cancelled or 
withdrawn firom consideration need not be submitted if the information is not material to the patentability 
of any claim remaining under consideration in the application. There is no duty to submit information 
which is not material to the patentability of any existing claim. The duty to disclose all information 
known to be material to patentability is deemed to be satisfied if all information known to be material to 
patentability of any claim issued in a patent was cited by the Office or submitted to the Office in the 
manner prescribed by §§ 1.97(b)-(d) and 1.98. However, no patent will be granted on an application in 
connection with which fraud on the Office was practiced or attempted or the duty of disclosure was 
violated through bad faith or intentional misconduct The Office encourages applicants to carefully 
examine: 

(1) prior art cited in search reports of a foreign patent office in a counteipart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentaibly defines, to make sure that any material 
information contained therein is disclosed to the Office. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made of record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refutes, or is inconsistent with, a position the applicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima facie case of unpatentability is established when the information compels a conclusion that a 
claim is unpatentable under the preponderance of evidence, burden-of-proof standard, giving each term in 
the claim its broadest reasonable construction consistent with the specification, and before any 
consideration is given to evidence which may be submitted in an attempt to establish a contraiy conclusion 
of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of 
this section are: 

(1) Each inventornamed in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Eveiy other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by disclosing 
infonnation to the attorney, agent, or inventor. 
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(2) the closest information over which individuals associated with the filing or prosecution of a 
patent application believe any pending claim patentably defioei; to make sure that any material 
information contained therein is disclosed to the C^ce. 

(b) Under this section, information is material to patentability when it is not cumulative to 
information already of record or being made of record in the application, and 

(1) It establishes, by itself or in combination with other information, a prima facie case of 
unpatentability of a claim; or 

(2) It refiites, or is inconsistent with, a position the applicant takes in: 

0) Opposing an argu|x»Qntofunpateo^ility relied on by the Office, or 

(U) Asserting an argument of patentatvUity. 
A prima facie case of unpatentability is established when the information compels a conclusion that a 
claim is unpatentable under the prepoi^derance of evidence, burden-of-proof standard, giving each term in 
the claim its broadest reasonable construction a>n»8teat with the specification, and before any 
consideration is given to evidence w]|ich may be suhfoitted in an attempt lo establish a contrary conclusion 
of patentability. 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of 
this section are: 

(1) Each inventor named in the applicatiofi; 

(2) Each attorney or agent if^o prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the 
application and who is associated with the inventor, with the assignee or with anyone to whom there is an 
obligation to assign the application. 

(d) Individuals other than the attorney, agent qt inventor may comply with this section by disclosing 
information to the attorney, agent, or inventor. 
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DECLARATION, POWER OF ATTORNEY, AND PETITION 

I, a bdow named mventor, depose and s£^ that: (1) my iestdence» citizenship^ and maiUng 
address aie indicated below; (2) I have reviewed and understand the contents of my patent application, 
including the claims^ as amended by any amendment specifically referred to herein^ which is identified as 
U.S. Patent Application Serial No. 08/723,504, filed Sqytember 30, 1996; (3) I bdieve that Richard A, 
Nazarian, Dirk R. Smith, James R. Watts; Timothy J. Kriewall, and I are the original, first, and joint 
inventors or discoverers of the invention or discovery in 

MEDICAL PERFUSION SYSTEM 

described and claimed therein and for which a patent is sought; and (4) I hereby acknowledge my duty to 
disclose to the Patent and Trademark Office all information known to me to be material to the 
patentability as defined in Title 37, Code of Federal Regulations, §1.56.* 

I hereby appoint Gary L. Griswold (Reg. No. 25,396), Walter N. Kim (Reg. No. 21,196), Tenyl 
K. Qualcy (Reg. No. 25,148), Warren R. Bovee (Reg. No. 26,434), Gerald F. (aiemivec (Reg. No. 26,53^, 
Douglas B. Little (Reg. No. 2S,439), David R. Cleveland (Reg. No. 29,524), Stephen W. Bauer (Reg. No. 
32,192), and Martin J. Hirsch, (Reg. No. 32,237) n^ attorneys and/or agents with fiill powers (including 
the powers of ^pointment, sul^tution, and revocation) to prosecute this application and any division, 
continuation, continuation-in-part, reexamination, or reissue thereof, and to transact all business in the 
Patent and Trademark Office coimected therewith; the mailing address and the telephone number of the 
above-mentioned attorneys and/or agents are 

Attention: Stq)hen W. Bauer 

3M Office of Intellectual Proper^ Counsel 

P.O. Box 33427 

St Paul, Minnesota 55133-3427 

Telephone No. (612) 733-1500 
The undersigned petitioner declares further that all statements made herein of his own knowledge 
are true and that all statements made on information and belief are believed to be true; arvd fiuther that 
these statements were made with the knowledge that willfixl Msc statements and the like so made are 
punishable by fine or imprisoiunent, or both, under Section 1001 of Title 18 of the United States Code and 
that such willful false statements may jeopardize the validity of the application or any patent issuing 
thereoa 

Wherefore, I pray for grant of Letters Patent for the invention or discovery described and claimed 
in the aforementioned specification and I hereby subscribe my name to the foregoing specification and 
claims, declaration, power of attorney, and this petition, on the day set forth below. 

Witness Richard A. Griewski Date 

Residence: Canton Township, Michigan USA 
J? . vxV Citizenship: United States of America 

^ ^A^>U-«:^_CV: /<£CiuU Post Office P.O. Box 33427 

Witness /] J Address: St Paul, Minnesota 55133-3427 
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§L56 Duty to disclose information material to patentability. 



(a) A patent by its veiy nature is affected with a public mterest. The public interest is best served, 
and the most effective patent examination occurs when, at the time an application is being examined, the 
Office is aware of and evaluates the teachings of aU information material to patentability. Each individual 
associated with the filing and prosecution of a patent application has a du^ of candor and good faith in 
dealing with the Office, which includes a duty to disclose to the Office all information known to that 
individual to be material to patentabiUty as defined in this section. The duty to disclose information exists 
with respect to each pending claim until tiie claim is canceUed or withdrawn fiom consideration, or tiie 
appUcation becomes abandoned Information material to tiie patentabiU^ of a claim tiiat is canceUed or 
witiidrawn from consideration need not be submitted if tiie information is not material to tiie patentabiliQr 
of any clahn remaining under consideration in flie application. There is no du^ to submit information 
which is not material to tiie patentabUity of any existing claim. The duty to disclose all information 
known to be material to patentabUity is deemed to be satisfied if all information known to be material to 
patentabiliQr of any claim issued in a patent was dted by tiie Office or submitted to tiie Office in tfie 
manner prescribed by §§ 1.97(b)-(d) and 1.98. However, no patent will be granted on an application m 
connection wifli which fraud on tfie Office was practiced or attempted or tiie du^ of disclosure was 
violated tiirough bad faitii or intentional misconduct The Office encourages applicants to carefully 

examine: . 

(1) prior art cited in search reports of a foreign patent office in a counterpart applicaUon, and 

(2) the closest information over which individuals associated witii the filing or prosecution of a 
patent application believe any pending claim patentably defines, to make sure tiiat any material 
information contained therein is disclosed to the Office. 

(b) Under tiiis section, information is material to patentabiUty when it is not cumulative to 
information alreacfy of record or being made of record in the application, and 

(1) It establishes, by itself or in combination witii otiier information, a prima facie case of 
impatentability of a claim; or 

(2) It refiites, or is inconsistent with, a position the ^plicant takes in: 

(i) Opposing an argument of unpatentability relied on by the Office, or 

(ii) Asserting an argument of patentability. 

A prima fade case of unpatentability is established when tfie information compels a condusion tiiat a 
claim is unpatentable under tiie preponderance of evidence, burden-of-proof standard, giving each term m 
tiie claim its broadest reasonable construction consistent wifli tfie specification, and before any 
consideration is given to evidence which may be submitted in an attempt to establish a contrary conclusion 
of patentability. 

(c) Individuals associated witfi tfie filing or prosecution of a patent application witiiin tfie meaning of 

this section are: 

(1) Each inventor named in the application; 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every otfier person who is substantively involved in tiie preparation or prosecution of tfie 
appUcation and who is assodated witii tiie inventor, witii tiie assignee or witfi anyone to whom tfiere is an 
obligation to assign the applicatioit 

(d) Individuals otfier tfian tfie attorney, agent or mventor may comply witfi tfiis section by disclosing 
information to the attorney, agent, or inventor. 



